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has  recently  proposed  [1J  a  new  programming  control  structure- 
construct  is  a  synthesis  of  several  ideas  in  programming 
iteration,  conditionals,  and  Dijkstra’s  guards  [2].  It  has 
in  a  LISP  interpreter  [8]  as  a  more  structured  replacement  for 
rog  construct.  Several  programming  examples  are  given  that 
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A.  Lain  Samples 


Abstract; 

D.  1.  Parnas  has  recently  proposed  [l]  a  new  programming  control 
structure  -  the  it-ti .  This  construct  is  a  synthesis  of  several 
ideas  in  programming  theory  including  iteration,  conditionals, 
and  Lip'kstra's  guards  [2].  It  has  been  implemented  in  a  LIT? 
interpreter  [9]  as  a  more  structured  replacement  for  the  tradi¬ 
tional  prog  construct.  Several  programming  examples  are  given 
that  compare  the  use  of  the  it-ti  with  the  more  conventional  pro¬ 
gramming  constructs.  These  examples  will  also  show  that  the  it- 
ti  fails  to  satisfy  several  criteria  for  programming  constructs 
including  manageability  and  visibility.  An  appendix  to  this 
report  contains  an  extension  of  Lijkstra's  concept  of  the  'weak¬ 
est  precondition'  to  the  it-ti. 


' .  Introduction 

L.  L.  Parnas  [ij  has  recently  proposed  a  new  programming  control 
structure  he  calls  the  it-ti  (iteration)  construct  after  the 
fashion  of  do-od,  if-fi ,  and  case-esac.  It  is  a  synthesis  of  two 
concepts  o7~  structured  programming  (iteration  and  conditional 
execution)  and  is  a  direct  descendant  of  Lijkstra's  do-od  and 
if-fi  [2].  Reference  [l]  contains  a  detailed  and  mathematical 
treatment  of  the  new  construct  for  both  non-deterministic  and 
deterministic  programming. 

While  the  it-ti  is  certainly  an  interesting  proposal  .and  has 
filled  a  niche  irDlavlisp,  we  will  see  that  it  fails  to  satisfy 
several  requirements  of  good  programming. 

To  motivate  the  new  construct,  let  -us  look  at  one  of  the 
thorns  of  structured  programming  [3]:  the  mid-exit  loop,  illus¬ 
trated  by  a  sequential  arrapr  search.  The  task  is  to  find  an  ele¬ 
ment  X  in  an  array  A.  If  it  is  found,  function  ?  is  passed  the 
index  of  an  element  of  A  that  contains  X.  If  it  is  not  fcuna, 
function  X  is  called  with  X  as  its  parameter.  A  straight¬ 
forward,  non-structured  implementation  in  pidgin-code*  of  this 
task  might  be: 


*  5y  pidgin-code  we  mean  to  indicate  a  language  that 

incorporates  features  of  several  languages,  and  that  we  are 
free  to  modify  as  the  need  arises. 


if  index  >  sizeof(A  “her.  goto  notfouni; 
if  'A[ index]  =  7.)  then  goto  found; 
index  : =  index  +  1 ; 
goto  icon; 

:i(X); 

goto  continue; 

7'  index' ; 

As  Xr.uth  [3]  points  out,  there  is  really  no  satisfactory  way  to 
solve  this  problem  with  'structured'  programming.  If  we  restrict 
ourselves  and  do  not  use  any  goto  statements,  we  might  solve  the 
problem  in  one  of  the  following  ways: 

Solution  _1_ 

found  :=  false; 
for  i  :=  1  to  sizeof(A)  do 
if  ( AT i ]  =  X)  then 
found  :=  true; 
index  :=  i; 
endif; 
endfor; 
if  (found) 

then  7( index'; 
else  'J(X); 
endif; 

Solution  2 


notfound : 

found : 
continue: 


found  :=  false; 
index  :=  1 ; 

while  (not  found  and  index  <=  sizeof(A')  do 
if  (A[ index]  =  X)  then  found  :=  true; 
else  index  :=  index  +  1 ; 
endwhile; 

if  (found)  then  ?( index); 
else  'I(K) ; 
endif; 


Solution  3 


index  :=  1 ; 

•while  (index  <=  sizeof(A)  cand  A[ index]  <>  X)  io 
index  :=  index  +  1 ; 
if  (index  >  sizeof(A))  then  N(K); 
else  P( index); 

Solution  1  is  obviously  inefficient.  She  whole  array  is  searched 
even  if  X  is  the  first  element.  This  could  be  an  important  con¬ 
sideration  if  the  array  A  is  large.  Solution  2  is  somewhat 
better,  but  the  truly  efficiency-minded  point  out  that  found 


removes  me  variable  but  iepends  on  conditional  evaluation  of 
boolean  expressions.  That  is,  the  right-hand  expression  of  a 

ffnq  is  evaluated  only  if  the  left-hand  expression  evaluates  to 


true.  In  our  example  the  cand  prevents  us  from  exceeding  the 
array  boards  of  A.  Tver  so,  this  solution  still  checks  the  value 


'•0^3  the  u°usQ  response  to  ^r±<5ss  3ms  is  ,,T,/ho 

^ares° ,f  *  s  ^u'S  '■'orr'sc"^  1*33x^01130  c ^  ^0.0  t imo  .  Tii0 

readability  and  maintainability  of  rode  .fast  take  precedence  over 
efficiency  almost  all  of  the  time.  However,  occasionally,  a 
piece  of  cede  will  occupy  a  critical  position  (e.g.  in  an  inner 
loop''  and  the  question  becomes  important.  Again,  the  usual 
response  is  "Code  it  in  assembly  language”.  Tut  this  implies 
that  readability  -and  maintainability  must  be  sacrificed  in  some 
situations  for  efficiency.  A  more  desirable  goal  is  a  set  of 
structured  programming  iisciplir.es  that  promote  readability  -and 
maintairability  without  sacrificing  efficiency. 


The  Tahn-oonstruct  [3.1] 
with  an  -scare  mecranism. 
search  wish  a  lahn  construct 


attempted  to  solve  this  problem 
The  following  implements  she _ array- 
fusing  the  notation  of  Knuth  *3]) . 


index  : =  1  ; 

locp  -until  found  or  net  found: 
if  .'Ai. index]  =  X)  then  foiund; 
index  :=  index  +  1; 
if  'index  >  sizeof(A))  then  notfound; 

repeat; 

then  found  =>  ?( index); 
notfound  =>  11  (X); 

-Pi  . 

come  find  this  less  satisfying  than  orthodox  structured  program¬ 
ming  or  programming  -with  geto  statements.  Tome  of  the  problems 
with  the  lahr.-ocnstruct  derive  from  one  structure's  lack  of  visi¬ 
bility  and  readability.  Tor  example,  to  trace  ore  results  of  a 
particular  e,rent,  'e.g.  foiund)  the  reader  must  scan  the  then 
clause  for  the  event  label  -  the  target  of  the  event  -  much  -as  he 
would  have  to  scan  for  the  target  of  a  goto.  '.Vhile  some  of  these 
problems  might  be  resolved  with  appropriate  syntactic  'sugar', 
the  Tahn-construct  is  still  a  not-very-well  disguised  goto, 
replete  with  label.  This  car  be  appreciate-!  better  by  drawing  tne 
control  flow  graphs  for  the  if-then— else,  repeat-until,  etc.,  and 
com  oar  ins  them  with  the  control  flow  vraon  for  the  laion— construct 
' o . v .  section  3.  below’:  the  lahr.-construct  does  not  have  a  sim¬ 
ple  flow  graph.  About  its  only  advantage  is  that  the  laar.- 
construct  forces  the  programmer  to  locally  ieciare  the  labels 
the  oontext  of  'use. 


.  i 


Parnas  has  proposed  a  generalization  of  Dijkstra's  do— od  (itera¬ 
tion)  and  if-fi  (conditional)  constructs.  The  basic  syntax  of 
she  it-ti  is  given  below  in  a  close  facsimile  of  Parnas'  nota¬ 
tion'*'  where  <break/repeat>  represents  one  of  the  keywords  break 
or  rereat. 


0<i 
pA 

pn  ->  sn  <break/repeat> 


— y  3^  'Co r s pile/ repeat > 
->  s2  <break/repeat> 
->  s3  <break/ repeat > 


The  semantics  of  the  it-ti  are  straightforward.  The  predicates 
pi  are  evaluated  sequentially  until  one  evaluates  to  true .  If  pj 
is  true,  then  the  sequence  of  statements  s.]  are  evaluated.  The 
last  element  of  sj  is  a  keyword  that  specifies  whether  the  it-ti 
is  to  be  executed  again  (repeat),  or  exited  (break).  It  is  an 
error  if  none  of  the  predicates  pi  evaluate  to  tree:  in  this 
case,  the  program  aborts. 

The  following  shews  hew  an  it-ti  could  be  coded  in  a  conven¬ 
tional  programming  language  like- Pascal,  Algol,  or  TCRTPki;. 

ithead: 

if  (?1 )  then  begin 
si ; 

goto  <label>;  j  where  <label>  is  ithead  :)a  repeat;  > 

1  or  ittail  (a  break)  ; 

end 

if  fp2)  then  begin 
s2; 

goto  <label>; 
end 


if  (pn)  then  begin 
sn; 

goto  <label>; 
end 

error( ” it-ti  fall  through”); 
ittail: 

!rest  of  program! 


*  The  notation  in  this  report  differs  from  Parnas  in:  1)  no 
elseor  -  the  predicates  are  assumed  to  be  executed 
ieterministically  and  sequentially;  (2)  no  up  and  down  arrows 
-  the  keywords  re neat  ani  break  axe  used  instead. 


<7J 


Arr‘iV 

fellows. 


index  :=  t ; 


index  >  sizeof(A)  ->  IT ( K ) ;  break; 

A[ index]  =  Pi  ->  H^index' ;  break; 

-)  index  i  =  index  **■  * 


This  seems  to  solve  most,  if  not  all,  of  the  problems  we  have 
mentioned:  there  is  no  redundant  boolean  variable  like  'found'; 
Che  search  -tons  when  the  element  is  located;  there  are  no  redun— 
ant  tests;  there  are  no  labels  that  redefine  the  'shape'  of  the 
truefure;  the  targets  of  the  aotos  implied  by  the  repeats  and 
breaks  are  visible  and  fixed;  and  any  compiler  worth  its  salt  can 
factor  out  the  constant  boolean  expression  at  code-generation 
time.  Here  we  have  a  tight,  efficient  sequence  of  code. 

The  traditional  control  structures  are  available  using  the 


Lf-then-else: 


if  b'  then 
bedyl ' 

else 

(body2> 
end  if 


b  ->  bedyl ;  break; 
true  ->  boay2;  break; 


for-looo: 


for  i  :=  1  to  n  do 
(body) 
end; 


i  :=  t; 
it 

i  <=  n  ->  (body)  ; 

i  :=  i  +  1 ; 
repeat ; 
true  ->  break; 
it 


while-loon: 


while  'b)  io 
'body 
end; 


b  ->  (body';  repeat; 
true  ->  break; 


;ase  x  of 

x * :  body1 ; 
x2:  bcdv2; 

xn :  bodvr. : 


=  xl  ->  bcdyl ;  break; 
--  x2  ->  bcdy2;  break; 

=  xn  — >  bcdyn;  break; 


unit  or 


->  'body';  rep- 
->  break; 


j7 .  Evaluation  of  the  it-ti 

There  are  several  valid  criticisms  of  the  it— ti.  Tor  example,  in 
order  to  handle  the  "execute  at  least  once'1  loops  ',e.g.  repeat- 
until,  and  the  FCRTRAN-66  DOioop)  a  new  feature  must  be  adaed  to 
the  it-ti  construct  (see  the  repeat-loop  implementation,  above): 
associate" with  each  it-ti  an  'init'  variable  that  is  true  only  on 
the  first  iteration.  And  to  prevent  unnecessary  evaluation  of 
the  boolean  'b'  in  this  structure,  we  most  also  require  condi¬ 
tional  evaluation  of  boolean  expressions  '.probably  not  an  'unrea¬ 
sonable  requirement,  but  one  forced  on  us  by  the  structure  of  the 
it-ti,  nevertheless). 

note  also  that  the  it-ti  ices  not  provide  for  efficient 
implementation  of  the  case^statement .  Without  further  enhance¬ 
ment,  the  it-ti  deprives  us  of  access  to  jump-table  or  hash-table 
implementation"  of  selection  constructs.  The  straightforward  if- 
then-elseif  approach  to  selection  is  not  appropriate  for  all  con¬ 
texts. 


Furthermore ,  practically  speaking,  the  it-ti  is  not  one  con¬ 
trol  structure  but  a  family  of  control  structures.  Unlike  a  con¬ 
ventional  repeat  or  while  in  which  we  knew  the  control  flew 
entailed  oy*  the  structure  without  -meowing  the  details  of  tne 
code,  the  introductory  keyword  of  the  it-ti  ices  not  give  us  any 
information  about  the  control  flow  of  the  following  code.  It 
simply  announces  that  a  section  of  code  has  been  reacned  which 
■will  contain  alterations  to  sequential  control  flow.  The  reader 
will  have  to  examine  the  body  of  each  it-ti  to  'understand  the 
nature  of  the  control  flow.  This  criticism  can  be  made  concrete 
by  observing  that  the  'traditional'  control  structures  have  a 
topologically  constant  flow  chart  representation  as  shown  in  Fig¬ 
ures  1  -  5  • 


dppuww 


e  lone  13  00  indicate  a 


figure  o.  ic-ti 

ihey  are  not  iecision  nodes  because  there  is  no  run-time 
ieoisicn  to  repeat  or  break:  the  programmer  makes  that  iecisior. 
it  iesign  time. 

Since  -an  it-ti  with  1  guard  clauses  has  possible  flcw- 
zraphs,  a  large  it-ti .  can  be  puite  complex  and  obscure,  and  fail 
to  satisfy  the  need  for  readable,  maintainable  code.  Ine  would 
tope  that  this  additional  complexity  would  be  justified  by  an 
improvement  in  cur  ability  to  express  algorithms,  especialljr 
'simple'  ones.  But,  there  is  still  a  simple  control  flow  graph 
''from  Xnuth  [?])  that  the  it-ti  cannot  handle  without  contortion, 
iijkstra  called  it  the  loop  that  is  executed  "n  and  a  half  times" 
'see  Figure  7) . 


figure  i7.  Dijkstra's  n-and-a-half-times  loop 

if  1  is  empty  we  have  a  while  loop,  and  if  7  is  empty  we  nave  a 
-ereat  loon.  In  suite  of  the  fact  that  the  it-ti  allows  us  to 


hand-craft  a  control  structure  to  meet  our  needs,  the  "n  and  a 
'naif  fines  loop"  does  not  have  a  simple  implementation  using  it. 
About  the  best  we  can  do  is  to  duplicate  S,  or  introduce  a 
boolean  variable. 

3; 

it 

b  ->  1;  3;  repeat; 
true  ->  break; 
ti 


toggle  :=  true; 
it 

toggle  ->  5;  toggle  :=  false;  repeat; 

b  ->  1;  toggle  :=  true;  repeat; 

true  ->  break; 

ti 

This  relatively  simple  control-flow  graph  can  be  implemented  with 
an  it-ti  if  we  make  a  further  extension  to  the  construct.  If  we 
allow  continue  (fall  through  to  the  next  guarded  statement)  as  an 
alternative  bo  break  or  repeat  then 

it 

true  ->  3;  continue; 
b  ->  T;  repeat; 
true  ->  break; 
ti 

would  do  precisely  what  we  wanted.  However,  continue,  like  the 
init  variable  introduced  earlier,  is  not  clean  and  is  very  ad  hoc 
in  nature.  It  increases  the  complexity  of  the  construct  Tthere 
are  now  3**N  possible  flow  graphs)  and  does  not 'enhance  the  visi¬ 
bility  of  the  code. 

And  now,  in  order  to  implement  intuitively  simple  programs, 
we  find  ourselves  going  through  the  same  contortions  with  the 
it-ti  that  we  have  gone  through  with  traditional  programming 
structures . 


Before  we  reject  the  it-ti  entirely,  however,  let  us  look  at  one 
context  in  which  the  Tt-tT  has  proven  effective. 

Veteran  LISP  programmers  say  have  a  feeling  of  deja-vu  with 
the  it-ti .  In  very  nan 7  ways,  it  resembles  the  cond  conditional 
of  LISP  except  that  the  send  ices  not  iterate.  For  non-veteran 
IIS?  programmers,  a  short  discussion  of  the  control-flow  struc¬ 
tures  of  LISP  follows. 


LISP  functions 


In  most  programing  languages,  a  function  is  called  with  syntax 
that  looks  something  like 

funename  ( parml  ,  parm2 ,  . . . ) 

A  LISP  function  application  looks  like: 

(funename  parml  parm2  ...) 

4.2  cond 

The  syntax  of  LISP'S  control  structure  for  conditional  execution, 
the  cond,  is  as  follows. 

( cond  (pi  si ) 

(?2  s2) 


(pn  sn) 

) 

The  pi  are  predicate  expressions  evaluating  to  the  LISP 
equivalents  of  true  or  false.  The  pi  are  executed  sequentially 
until  one  of  them,  say  pj,  evaluates  to  true.  At  that  point,  the 
list  of  statements  sj  is  evaluated.  When  all  of  the  statements 
in  statement  list  sj  are  evaluated,  interpretation  commences  at 
the  first  program  statement  after  the  final  parenthesis  of  the 
cond. 


4-3  prog 

McCarthy  [7]  reports  that  he  originally  intended  that  LISP  would 
be  a  FORTRAN-like  list  processing  language  with  the  addition  of 
recursion  and  conditional  evaluation  of  boolean  expressions.  He 
also  admits  that  prog  looks  like  an  "afterthought" ,  and  that  its 
design  was  an  "afterthought" .  But  it  is  this  control  structure 
that  provides  iteration  via  labels  and  £0.  If  we  assume  that 
(An)  is  a  function  that  returns  the  nth  element  of  the  array  A, 
then  the  array  search  problem  could  be  ’written  in  LISP  as  fol¬ 
lows. 


-10- 


setq  index  1 

loop  ;this  is  just  a  label,  not  a  LISP  keyword 
(cond  ((greaterp  index  (sizeof  A))  (go  notfouna)) 
((eaual  (A  index)  K)  (go  found)) 

(setq  index  (addl  index)) 

go  loop  ^ 
notfourvi 

( return ) 
found 

(?  index ) 

( return ) 


A  tore  efficient  LISP  program  to  perform  this  search  would  be: 

(prog  (index) 

(setq  index  1 ) 
loop 

(cond  ((greaterp  index  (sizeof  A))  (N  X)  return) 

((equal  (A  index)  X)  (F  index)  return) 

) 

(setq  index  (addl  index)) 

(go  loon) 

) 


One  can  see  that  this  transliteration  from  our  pidgin-code  into 
LISP  results  in  FORTRAN-like  code  which,  when  one  thinks  about 
it,  is  a  far  cry  from  the  programming  style  indicated  by  the  rest 
of  the  LISP  language:  this  goto  style  of  programming  is  an  abdi¬ 
cation  of  the  applicative  nature  of  LISP. 


5-  An  alternative  to  prog 

A  moment’ 3  thought  will  convince  you  that  it  is  easy  enough  to 
incorporate  the  it-ti  construct  into  LISP.  The  syntax  of  the 
cond  is  modified  to  accept  one  of  the  keywords  break  or  repeat  at 
the  end  of  the  statement  list.  The  keyword  break  specifies  that 
control  exits  the  cond.  The  keyword  repeat  specifies  that  the 
cond  is  to  be  repeated .  I.e., 

(cond  (pi  si  r repeat /break]) 

(p2  s2  [repeat /break]) 


(pn  sn  [repeat /break]) 


There  are  some  differences  between  the  enhanced  cond  in  'iavlisp 
and  Parnas’  strict  definition  of  the  it-ti .  For  upward 
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repeat  /break  is  optional  since  the  conventional  cor.i  is  iefir.ed 
as  if  break  were  at  the  end  of  each  statement  list"!  nnd  for  the 
same  reason,  the  cond  does  not  abort  if  all  of  the 
guards /predicates  are  false.  Unfortunately,  this  results  in  the 
loss  of  one  of  the  distinct  advantages  of  the  it-ti :  providing  an 
effective  run  time  check  that  each  case  has  been  anticipated. 

With  this  enhancement  to  cond ,  the  coding  of  our  example  is 
concise: 

(seta  index  1) 

( cond 

((greater?  index  (sizeof  A))  (IT  X)  break', 

((equal  (A  index)  K)  (P  index)  break) 

(T  (setq  index  (addl  index))  repeat) 


Note  again  that  the  keyword  break  is  not  necessary  since  that  is 
the  default  action  of  the  LISP  cond. 


5-1  Sxamples 

Winston  [5],  page  328,  defines  a  non-recursive  factorial  function 
which  is  reproduced  below: 

(defun  factorial  (n)  ;  written  in  Maclisp 

(prog  (result  counter) 

( setq  result  1 ) 

(setq  counter  n) 

loop  ;  note  the  label 

(cond  ((zerop  counter)  (return  result))) 

(setq  result  (times  counter  result)) 

(setq  counter  (subl  counter)) 

(go  loop))) 

The  following  shows  the  result  of  defining  the  function  using  the 
modified  cond. 

(defun  factorial  (n)  ;  'written  in  Navlisp 

(let  ((result  1)  (counter  n)) 

(cond  ((zero?  counter)  result  break) 

(T  (setq  result  (times  counter  result)) 

(setq  counter  (subl  counter)) 
repeat ) ) ) ) 

The  let  'used  in  the  above  example  is  a  LISP  function  which,  like 
the  begin  of  Algol  and  the  curly  brace  ' {'  of  C,  defines  an 
environment  with  local  variables.  That  is,  let  is  simply  a  prog 
without  the  complications  of  labels,  £0,  and  return.  In  Maclisp, 
let,  prog,  and  an  unmodified  cond  are-  available.  In  Navlisp, 
only  the  let  and  the  enhanced  cond  are  necessary. 


I 


! IcCarthy  [-3],  page  25,  illustrates  the  use  of  proj  with  a 
program  to  compute  the  length  of  a  list.  His  version  of  tnis 
function  uses  proa: 

(defun  length  (list) 

(prog  (u  v) 

(setq  v  0) 

(seta  u  list'' 

a  'cond  ((null  u)  (return  v' ' ' 

( setq  u  ( cdr  u ) ) 

(setq  v  (addl  v)) 

(go  a)  )) 

The  following  is  a  version  'using  the  modified  cond. 

(defun  length  (list) 

(let  ((v  0)  (u  list)) 

(cond  ((null  u)  v  break) 

(T  (setq  u  (cdr  u)) 

(setq  v  (addl  v)) 
repeat ) ) ) ) 

A  more  intricate  example  comes  from  Winston  [5],  page  334.  If  we 
assume  that  (matrix  i  j)  is  a  function  that  returns  the  ( i , J ) 
element  from  a  two-dimensional  array  named  matrix,  then  Winton's 
version  using  prog  is: 

(defun  print-matrix  (n  m)  ;  written  in  Maclisp 
(prog  (i  j) 

(setq  i  0) 
row-loop 

(cond  ((equal  i  n)  (return  nil))) 

(terpri)  ;  prints  an  end-of-line 

(setq  j  0) 

column-loop 

(eond  ((equal  j  m)  (go  next-row))) 

(princ  (matrix  i  j)) 

(princ  '!  !)  ;  prints  a  blank 

(setq  j  (addl  .j)) 

(go  column-loop) 
next-row 

(setq  i  (addl  i)) 

(go  row-loop))) 


Thi3  program  prints  out  the  elements  of  a  two-dimensional  array  a 
row  at  a  time.  The  following  is  the  Navlisp  equivalent  using  the 
it-ti  form  of  cond: 


■51* An  ’?r.ir-r.3,*rix  v.  **’  •  ir» 

**  0+  i  *  '.  ’  •  -■  ■?  0  *10"^  i  *T'  ^  ~i  q  |  7 

(cond  v(ecual  i  n;  nil  creak,' 

(1  (terpri) 

(setq  j  0) 

(cond  ((equal  j  a)  break) 

(T  (printf  (matrix  i  j)  ”  ") 

(setq  i  (addl  j'1) 
repeat , ) 

. setq  i  'addl  i)) 
repeat ) ) ) ) 

Our  final  example  is  the  LISP  interpreter  function  evccn  coded  in 
faviisn. 


(defun  evcon  (beg  a) 

(let  ((c  beg)) 

(cond  ((null  c)  break) 
((eval  (caar  c)  a) 


(let  ((slist  (cdar  c))  (s  (car  (caar  c)))) 

(cond  ((null  s)  (set  'c  (cdr  c))  break) 

( (atom  s) 

(cond  ((equal  s  ’repeat)  (set  'c  beg) 
break) 

((equal  s  'break  )  (set  'c  nil) 
break) 

(I  (eval  s  a) 

(set  'c  (cdr  c)) 
break)) 

break) 

(0  (eval  s  a) 

(set  'slist  (cdr  slist)) 

(set  's  (cond  ((not  (null  slist)) 

(car  slist)))) 

repeat))) 

repeat ) 

(T  (set  'c  (cdr  c))  repeat) 


Conclusions 


Computer  Science  as  a  field  is  always  on  the  lookout  for  program¬ 
ming  concepts  that  simplify  the  art  of  programming.  Parnas'  it- 
ti  is  an  interesting  proposal  to  that  end,  but  does  have  several 
serious  drawbacks.  However,  the  it-ti  has  proved  itself  a  very 
apt  programming  structure  for  LISP,  allowing  the  complex  prog  to 
be  replaced  by  an  enhancement  to  cond.  The  new  cond  is  slightly 
more  complicated  than  the  old,  but  allows  the  writing  of  itera¬ 
tive  programs  whose  structures  are  more  within  the  programming 
spirit  of  LISP.  This  structure  has  been  implemented  in  Navlisp 
and  has  proved  itself  to  be  both  compact*  and  sufficient. 


Acnendix 


In  [2],  Dijkstra  develops  a  programming  language  conducive  to 
correctness  proofs  in  which  he  defines  two  constructs  he  calls 
if-fi  and  do-od.  He  introduces  the  concept  of  the  'weakest 
precondition',  written  wol'S,?.’'  and  paraphrased  as  "The  necessary 
conditions  which  guarantee  that  execution  ot\  statement  2  will 
leave  the  computation  in  state  H.’  Parnas  cites  Pi,>:stra 
as  his  inspiration  for  the  it-ti,  noting  that  it  is  a  modifica¬ 
tion  of  the  do-od  and  the  if-Fi .  He  does  not,  however,  attempt 
to  apply  Pi jkstraTs  'weakest  precondition'  to  the  it-ti .  ?or 
completeness,  it  is  included  here.  The  reader  is  referred  to  [2] 
for  a  complete  discussion  of  the  development  of  the  weakest 
precondition  for  the  do-od  and  if-fi .  It  should  also  be  noted 
that  the  following  discussion  assumes  non— determinacy ,  as  do 
Pijkstra  and  Parnas. 

Let  IT  refer  to  the  it-ti: 

it 

31  ->  SI 

32  ->  32 


3n  ->  2n 
ti 

•where  the  last  statement  in  each  Si  is  either  break  or  repeat . 
At  least  one  of  the  3i  will  evaluate  to  true  (otherwise  the 
results  are  undefined  and  will  abort  execution  of  the  program) . 
That  is,  'using  the  notation  in  [2]**: 

(Hi  :  1  <=  i  <=  n  :  Bi) 

Since  the  construct  is  non-deterministic,  we  can  re-arrange  the 
statements  such  that: 

(Tin  :  (0  <=  m  <=  n)  : 

(Ai  :  f(1  <=  i  <=  m)  and  (Si  ends  with  'repeat')] 
or  f(m  <=  i  <=  n)  and  (Si  ends  with  'break')  J  )) 

If  m  =  0  then  the  construct  corresponds  to  Dic’kstra's  if-fi ,  and 
if  m  =  n  the  construct  is  an  infinite  loop.  This  is  effectively 
equivalent  to  the  following: 


*  It  may  interest  some  to  know  that  it  required  only  six 
additional  lines  of  T-code  to  the  Havlisp  interpreter  to 
implement  the  enhanced  cond. 

"*  The  notation  ’uses  Hi  to  mean  'there  exists  an  i ' , 
mean  ' for  all  i ' . 


and  Ai  to 


ct  OJ 


22  ->  22 

Bm  ->  3m 
oa 

B(m+1  ^  ->  3(m+l ) 

Bn  ->  3n 

true  ->  error 


^The  last  statement  of  the  if  is  necessary  if  m  =  n.)  Rote  that 
this  assumes  that  for  any  iteration  either 

(Ai  :  3i  :  (Aj  :  Bj  :  Ti  in  (1  ,m)  and  j  in  (1,m)] 

or  [i  in  (m+1 ,n)  and  j  in  (m+1,n)]  )} 

or  that  do-od/repeat  statements  take  precedence  over  if-fi/break 
tatements  if  more  than  one  Bi  is  true.  With  these  qualificat¬ 
ions  on  the  it-ti  we  can  arrive  at  its  weakest  precondition. 
Let  DO'  represent  that  sub-part  of  the  it-ti  that  repeats ,  and 
IP'  represent  that  sub-part  of  the  it-ti  that  breaks,  then 

wp(IB,R>  =  wp(DC ,  wpC?’,?.)  ) 

where  (from  [2]) 

wp(I7',R)  =  (Ej  :  m  <  j  <=  n  :  3j)  and 

(Aj  :  m  <  j  <=  n  :  Bj  =>  wp(2.j,P.)) 

wp(DC',R)  =  (Ek  :  k  >=  0  :  Hk(R) ) 

Hk(R)  =  wp(IF,  H(k-1 ) (R) )  or  H(k-1)(R) 

H0(R)  =  R  and  not  (Ej  :  1  <=  j  <=  a  :  Bj) 
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